École Nationale des Sciences Géographiques
Décembre 2017 - Damien DUPORTAL
This work is licensed under a http://creativecommons.org/licenses/by/4.0/
Training Engineer @ CloudBees
Docker & Apple fanboy.
Human stack focused
Rock climber
Contact:
Twitter: @DamienDuportal
Github: dduportal
eMail: damien.duportal@gmail.com
TBD.
TBD.
"Gestion de Code Source"
Les Gestionnaires de Code Source, également connus comme "Version Control Systems" (VCS):
Sont des systèmes logiciels
Conservent toutes les modifications apportées à une collection de fichiers, dans le temps
Permettent de partager ces changements
Fournissent des fonctionnalités de merge et de suivi des modifications
Pour collaborer efficacement sur un même référentiel de code source
Aide à la résolution de conflits
Partage de contenu facile
Pour conserver une trace de tous les changements : On parle de source unique de vérité (Single Source of Truth)
Historique complet des modifications
Possibilité de retour arrière à tout moment
Locaux
Centralisés
Distribués
Plus vieux type, ancêtre de tous les autres
Uniquement historique de modification
Utilise une "base de donnée de versions" des fichiers
Stockage uniquement des différences ("diff")
Pas de partage
Exemple: rcs (toujours dans Apple XCode Tools)
Couvre historique ET partage
La "base de données de versions" est stockée sur un serveur central
Chaque client ne possède qu'une seule version du code
Apprentissage très facile, limité sur la résolution de conflits
Exemples: CVS, SVN, Perforce, TFS
La "base de données de versions" est distribuée par duplication sur chaque noeud
Exemples: Git, Mercurial, Bazaar, Monotone
Hébergés dans le Cloud
Hébergé "à la maison"
SCM as a Service
Le serveur centralisé est un service hébergé par un fournisseur
Avantages:
Pas de temps/énergie passés sur la gestion
Associent au SCM d’autre services : gestionnaire de tickets, wiki, éditeur de texte online, etc.
Risque: Votre code est hébergé par un tiers
Exemples: GitHub, Bitbucket by Atlassian, Amazon CodeCommit, Visual Studio Online by Microsoft, SourceForge, GitLab.com, etc.
Pour pallier au risque précédent, on trouve des versions "On-Premide" (généralement payantes)
Le monde de l’Open Source fourni également des solutions à héberger soit-même
Très souvent gratuit et on peut le corriger
Temps et énergie à consacrer
Exemples: Gitlab, Gitea, Gogs, Bazaar server, VisualSVN Server, etc.
diff: un ensemble de lignes "changées" sur un fichier donné
changeset: un ensemble de "diff" (donc peut couvrir plusieurs fichiers)
commit: Action de sauvegarder un changeset dans la base de données des versions.
Le dernier commit dans l’historique est aliasé comme "HEAD"
Abstraction d’une version "isolée" du code
Concrètement, une branche est un alias pointant vers un "commit"
On intègre une branche dans une autre en effectuant un merge
Un nouveau commit est créé, fruit de la combinaison de 2 autres commits
Une Pull Request (ou "Merge Request") est une procédure de revue de code avant intégration
Voici quelques motifs d’utilisation des SCMs :
"Centralized" Flow
"Feature Branch" Flow
"Git" Flow
"GitHub" Flow
Une seule branche par fonctionnalité
"Infrastructure as Code" :
Besoins de traçabilité, de définition explicite et de gestion de conflits
Collaboration requise pour chaque changement (revue, responsabilités)
Code Civil:
Un peu de lecture :
Le code est donc sujet à erreurs: Conséquences?
Les tests identifient ces erreurs, dans un but de correction
Le test logiciel est une pratique suivant 2 piliers :
Valider que le logiciel remplisse les rôles qui lui sont confiés
Rechercher les fautes pour les corriger, améliorant la qualité du système
Automatiser : répétition et reproductibilité
Test Manuel à considérer dans peu de cas, quand :
Coût de l’automatisation dépasse sa valeur
Automatisation impossible
SUT: "System Under Testing". Défini les frontières du système.
Test Double: Terme générique désignant un sous-ensemble simplifié du "S.U.T.". Exemples: Mock, Stub, Spy, etc.
Boîte Blanche: Tester avec une vue interne du SUT
Boîte Noire: Tester le SUT sans connaissance préalable de ses mécanismes interne
La question primordiale est: "Que voulez-vous tester ?"
En fonction de la réponse, différent types de tests peuvent être utilisé (liste NON exhaustive) :
Unit testing
Integration testing
Smoke testing
Functional Testing
Non-Regression testing
Acceptance testing
Focalisé sur le plus petit sous sytème possible du SUT, en "boîte blanche"
Tests indépendants les uns des autres
Ordre d’exécution non important
Utilisation de Test Doubles pour simuler le "reste" en bon fonctionnement
Vérifier l’intégration entre différents sous-systèmes
Le SUT est en "boîte blanche"
But : Fail Fast en "boîte blanche"
Valide les fonctions "de base" du système
On parle parfois de "Sanity Checking"
If it smokes, it’s bad
Vérifie que le logiciel se comporte comme prévue par les personnes en charge de la fabrication
Pas de biais d’inteprétation
Le SUT est en "boîte noire"
Vérifie que le SUT a un comportement stable dans le temps
Focalisation sur bug qui ne doit pas revenir
Le SUT est en "boîte noire"
Correcting a single bug may introduce several more.
Également connu sous l’acronyme "UAT" User Acceptance Testing
Vérifie que le logiciel se comporte comme attendu par l’utilisateur
Biais de communication inclus
Le SUT est en "boîte noire"
Fonction des temps d’exécutions, des coûts de corrections, et des valeurs ajoutées. Contextuel.
TDD: Écrire les tests unitaires avant le code
BDD: Privilégier language naturel et interactions
"Given, When, Then"
Moins de technique. Valeur ajoutée pour l’utilisateur.
Continuous Integration is a software development practice where members of a team integrate their work frequently. Usually each person integrates at least daily - leading to multiple integrations per day.
Construire et intégrer le code en continu
Le code est intégré souvent, au moins quotidiennement pour que l’intégration soit un non-évenement
Chaque intégration est validée par une construction automatisée avec tests
But : Détecter les fautes au plus tôt
Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.
Continous Delivery (CD)
Diminuer les risque liés au déploiement
Permettre de récolter des retours utilisateurs plus souvent
Rendre l’avancement visible par tous
How long would it take to your organization to deploy a change that involves just one single line of code?
Suite logique de l’intégration continue:
Chaque changement est potentiellement déployable en production
Le déploiement peut donc être effectué à tout moment
Your team prioritizes keeping the software deployable over working on new features
Continuous Deployment
Version "avancée" de la livraison continue:
Chaque changement est déployé en production, de manière automatique
Question importante: En avez-vous besoin ?
Avez-vous les mêmes besoin que Amazon Google ou Netflix ?
"Software Supply Chain"
"Feedback loop" / "Boucle de feedback"
Problèmatique : réagir rapidement pour corriger une faute
"Au plus tôt, au moins cher"
Problème #1: Avoir un retour
Problème #2: Réagir systématiquement sur un retour
Problème #3: Avoir confiance
Quels acteurs du système ?
Quel médium de communication ?
Quel déclencheurs et quelles limites ?
Culture à construire, les outils suivent facilement
Industrialisation du logiciel
Modélisation de la chaîne de valeur ("Value Stream Mapping")
"Fast is cheap": Piloté par le concept de la défaillance rapide ("fail fast")
Stage ("étape"): Élément de base
Abstraction atomiques d’un ensemble d’actions
Exemple: "Build", "Run Unit Tests"
Possibilité de parallèlisation
Gate ("Porte"): Transition entre 2 étapes
Manuel ou automatique
Peuvent être conditionnelles
Déclenchement initial : un changement dans la base de code
Chaque étape peut produire des livrables: on parlera d'Artefacts dans ce cours
Le déploiement est ce qui permet de rendre le logiciel prêt à l’usage
Un "déploiement" est exécuté vers un environnement
Production
Préproduction ("staging") / recette ("qualification")
Tests
"Disaster Recovery Environment"
Commencer par un "Produit Minimum Viable" (MVP) puis itérer
S’efforcer d’appliquer les bonne pratiques
Optimiser le Pipeline (lors des itérations)
Réutilisation des artefacts: "Only Build Your Binaries Once"
Arrêt du Pipeline dès qu’une faute est identifiée: "Fail Fast"
Identifier si un artefacts n’est pas déployable (tests…)
S’assurer qu’une même version de la base de code est utilisée à tout moment pour un Pipeline donnée
Paralléliser les étapes
Arrêt du Pipeline si une "branche" est en erreur
Sinon: étape inutile à supprimer
Les "gates" manuelles peuvent également être paralleliser
relation "1-N": N "gates" manuelles déclencheront N étapes parallèles
Un peu de lecture :
Votre organisation utilise l'information pour créer de la valeur
L’information doit donc être:
Confidentielle
Intègre
Disponible
C’est l’ensemble des pratiques et des outils permettant de prévenir et combattre les menaces sur l’organisation
4 piliers:
Connaissance du sytème
Least Privilege
Défense en profondeur
Mieux vaut prévenir que guérir
AAA signifie :
Authentification
Authorisation
Accounting (comptabilisation)
C’est l’ensemble des procédures et outils pour identifier un acteur avec une confiance suffisante
Une fois l’acteur identifié avec confiance, il faut contrôler ses droit en terme de manipulations
Nomenclature :
Ressources: Tâches ou objets manipulables et accessibles
Rôles: Ensemble de droits regroupés par commodité
Requêteurs: Acteur souhaitant manipuler des ressources
Etre autorisé à manipuler des ressources ne garantie pas l’effection à 100%
Limites du système (mémoire, disque, consommation, temps, etc.)
Erreurs, pannes et fautes
L'"accounting" permet de mesurer et contrôler les manipulations
Respect des limites
Reprises sur erreur
Capacity planning
Un peu de lecture :